home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9703 / 000012_owner-urn-ietf _Sat Mar 8 14:56:32 1997.msg < prev    next >
Internet Message Format  |  1997-04-01  |  3KB
  1. Received: (from daemon@localhost)
  2.     by services.bunyip.com (8.8.5/8.8.5) id OAA08757
  3.     for urn-ietf-out; Sat, 8 Mar 1997 14:56:32 -0500 (EST)
  4. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
  5.     by services.bunyip.com (8.8.5/8.8.5) with SMTP id OAA08752
  6.     for <urn-ietf@services.bunyip.com>; Sat, 8 Mar 1997 14:56:29 -0500 (EST)
  7. Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  8.         id AA27993  (mail destined for urn-ietf@services.bunyip.com); Sat, 8 Mar 97 14:56:27 -0500
  9. Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) 
  10.           id <27002-0@josef.ifi.unizh.ch>; Sat, 8 Mar 1997 20:56:36 +0100
  11. Date: Sat, 8 Mar 1997 20:56:35 +0100 (MET)
  12. From: "Martin J. Duerst" <mduerst@ifi.unizh.ch>
  13. To: "Ron Daniel Jr." <rdaniel@acl.lanl.gov>
  14. Cc: "Karen R. Sollins" <sollins@ginger.lcs.mit.edu>, urn-ietf@bunyip.com
  15. Subject: Re: [URN] NAPTR doc (draft-ietf-urn-naptr-03.txt)
  16. In-Reply-To: <3.0.32.19970307222124.00994df0@acl.lanl.gov>
  17. Message-Id: <Pine.SUN.3.95q.970308113158.245V-100000@enoshima>
  18. Mime-Version: 1.0
  19. Content-Type: TEXT/PLAIN; charset=US-ASCII
  20. Sender: owner-urn-ietf@Bunyip.Com
  21. Precedence: bulk
  22. Reply-To: "Martin J. Duerst" <mduerst@ifi.unizh.ch>
  23. Errors-To: owner-urn-ietf@Bunyip.Com
  24.  
  25. On Fri, 7 Mar 1997, Ron Daniel Jr. wrote:
  26.  
  27. > Hi Karen,
  28. > 
  29. > >Second, I don't have the Posix regular expression description here (or for
  30. > >that matter anywhere in my office).  I suspect that is true of many people.
  31. > 
  32. > It's more widespread than you might think. Most UNIX machines are POSIX
  33. > compliant now, so they have a regex library and man pages that talk about
  34. > EREs.
  35.  
  36. POSIX is locale-dependant. It is important to specify exactly
  37. what locale is used, otherwise, you get uncontrolled behaviour.
  38.  
  39. Also, it's important to say exactly how NAPTR in general and regex
  40. application interacts with several aspects of the syntax. For example,
  41. are NAPTR records stored in %HH-escaped form? DNS can contain 8-bit
  42. data, and the %HH escaping, for octets above 0x80, seems unnecessary.
  43. Are regexps applied to %HH, or to binary octets, or to UTF-8 characters?
  44. (The later would be possible with an UTF-8 posix locale. I don't
  45. propose that this solution is taken, but I want to point out that
  46. there are indeed UTF-8 locales.) Saying that regular expressions
  47. with international characters are impossible to build by hand
  48. seems to imply that at least they work on octets, if not on
  49. %HH. That should at least be made explicit.
  50.  
  51. In addition, maybe it would pay off to change the formatting
  52. to internet-draft/RFC conventions. At some stage, this has
  53. to be done anyway :-(.
  54.  
  55.  
  56. Regards,    Martin.
  57.  
  58.